Skip to content

Handle NIOSSLError.uncleanShutdown correctly #472

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

fabianfett
Copy link
Member

Motivation

Fixes #238 and #231.

Changes

Result

ignoreUncleanSSLShutdown on HTTPClient.Configuration is deprecated and ignored.

@fabianfett fabianfett requested review from weissi and Lukasa November 10, 2021 15:38
Copy link
Contributor

@weissi weissi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awesome, thank you so much!

// if we have already received the response head, the parser will ensure that we receive
// the complete response. we can ignore this error. we might see a HTTPParserError very
// soon.
if responseHead.headers.contains(name: "content-length") || responseHead.headers.contains(name: "transfer-encoding") {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a sufficient check: there are cases where these headers are not present, but we are nonetheless confident of the length of the response. Specifically:

  1. Responses to a HEAD request
  2. Responses with a 204 or 304 status code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The HTTPResponseDecoder will always emit a response .end after having received a response head, if the request had a HEAD or CONNECT method or the response status is 204 or 304.

https://github.com/apple/swift-nio/blob/main/Sources/NIOHTTP1/HTTPDecoder.swift#L301-L314

For this reason, we can expect that we will only be in the streaming state, if we have a "content-length" or "transfer-encoding" header or if the response is EOF terminated. I'm well aware that this is very implicit. If we want to have explicit checks here, I will need to come up with a way to preserve the request method a little longer.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, can we get this logic into a comment then? The correctness of this code is not apparent merely from reading it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment added.


// if we have already received the response head, the parser will ensure that we receive
// the complete response. we can ignore this error. we might see a HTTPParserError very
// soon.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment seems to be out of step with the code: it implies that we can ignore the error, but then has logic that sometimes doesn't ignore the error.

@fabianfett fabianfett force-pushed the ff-verify-unclean-shutdown-is-solved branch 2 times, most recently from 36a9c6d to 5b5931b Compare November 11, 2021 09:41
@Lukasa Lukasa added the 🆕 semver/minor Adds new public API. label Nov 11, 2021
@fabianfett fabianfett force-pushed the ff-verify-unclean-shutdown-is-solved branch from 5b5931b to 3e03472 Compare November 11, 2021 09:48
@fabianfett fabianfett merged commit 7617c35 into swift-server:main Nov 11, 2021
@fabianfett fabianfett deleted the ff-verify-unclean-shutdown-is-solved branch November 11, 2021 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🆕 semver/minor Adds new public API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

uncleanShutdown should be handled automatically (where possible)
3 participants